home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
e
/
misc.save
/
000177_bonomi@host122.r-bonomi.com_Mon Jun 30 09:41:37 2008.msg
< prev
next >
Wrap
Internet Message Format
|
2011-07-03
|
4KB
Path: reader2.panix.com!panix!newsfeed.stanford.edu!postnews.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.posted.nuvoxcommunications!news.posted.nuvoxcommunications.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Jun 2008 20:22:27 -0500
Newsgroups: comp.protocols.kermit.misc
References: <dd9ih5-31m.ln1@CPE-124-182-119-184.sa.bigpond.net.au> <slrng52q33.cri.fdc@panix2.panix.com>
Organization: Gizmos & Gadgets, Ltd.
Subject: Re: compiler warning when compiling ftp://ftp.columbia.edu/kermit/test/tar/x.tar.gz
X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
From: bonomi@host122.r-bonomi.com (Robert Bonomi)
Originator: bonomi@host122.r-bonomi.com (Robert Bonomi)
Message-ID: <NqKdnau5iKTOm8bVnZ2dnUVZ_jadnZ2d@posted.nuvoxcommunications>
Date: Thu, 19 Jun 2008 20:22:27 -0500
Lines: 61
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 204.87.227.26
X-Trace: sv3-ut2180YT/MdRaZQnVkpz5l+J37MrxBkwJCVor8ZwMnc9Ls0LnnhwriSFWmxA1D204f9ZJgJ76Ix3flg!hJz0HHfj+PSohgzD0AcBPsRnJqrjXGm1xRlpzfZGwiYl4qJrLT+zZKhfY21/1nqFrADj7BRA1COR!18n+1u3YWr7M1tnIZ+9U19sY6HRkFQxdaVSvtlJJc9k=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.39
Xref: panix comp.protocols.kermit.misc:15769
In article <slrng52q33.cri.fdc@panix2.panix.com>,
Frank da Cruz <fdc@columbia.edu> wrote:
>On 2008-06-04, Arthur Marsh <arthur.marsh@internode.on.net> wrote:
>: I don't know if this is worth checking:
>:
>: gcc-4.3 -O3 -march=pentium2 -funsigned-char -pipe -DPOSIX -DLINUX
>: -DNOCOTFMC -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>: -DCK_AUTHENTICATION -DCK_SSL -DCK_PAM -DZLIB -DCK_CURSES -DCK_POSIX_SIG
>: -DTCPSOCKET -DLINUXFSSTND -DHAVE_CRYPT_H -DFNFLOAT -DCK_SHADOW
>: -I/usr/include/openssl -DOPENSSL_097
>: -DKTARGET=\"linux+openssl+zlib+shadow+pam\" -c ckuusx.c
>: ckuusx.c: In function 'ck_termset':
>: ckuusx.c:6181: warning: cast from pointer to integer of different size
>: ckuusx.c:6188: warning: cast from pointer to integer of different size
>: ckuusx.c:6195: warning: cast from pointer to integer of different size
>:
>This is something in the termcap / termlib / ncurses library. I'd say
>if the file-transfer display still works OK (which is really the only
>things that uses curses, except a few commands like CLEAR SCREEN), then
>it's nothing to worry about.
>
>: ck_ssl.c: In function 'tls_load_certs':
>: ck_ssl.c:1171: warning: cast from pointer to integer of different size
>: ck_ssl.c:1172: warning: cast from pointer to integer of different size
>:
>: This is being compiled on Debian GNU/Linux unstable on a Pentium II machine.
>:
>I'm told that these are nothing to worry about either. We've always had
>tons of warnings when building with the security libraries and header files,
>yet the features still work OK when used. Still, it would be nice avoid the
>warnings.
_ALL_ these statements are invocations of the 'debug()' macro. 'debug()'
expands to a function where the 4th parameter is defined as a CK_OFF_T.
The offending invocations all have a 4th parameter that is a "pointer to
something". Which *VIOLATES* the specification of the dodebug() routine
(in ckuusx.c, line 4849) that the debug() macro expands to.
Anyway, the result is a "size mis-match" in these circumstances
between a (void *) and a CK_OFF_T.
CK_OFF_T is specced as a type big enough to hold a _file_ offset, and
since it's being compiled with _LARGEFILESOURCE this is a 64-bit qty.
_APPARENTLY_, the compilation options only use a 32-bit _program_ address-
space, thus generating the mis-match.
FIX:
ckuusx.c -- change the last parameter of debug() from "" to 0 on all 3 lines.
ck_ssl.c -- no obvious foolproof fix here. Explicitly casting the last
param of the macro to an 32-bit qty -- e.g. "debug(..((int32)ctx))"
should work, as long as there is a defined 'int32' type.
`
[ I'm assuming that sooner or later somebody _will_ try to compile ]
[ C-Kermit on a machine with 32-bit pointers, but only 16-bit ints. ]
[ If one decides that it is 'safe' to ignore that case, then a simple ]
[ ((int)ctx) would work. ]